Open in StackBlitz

npm i https://pkg.pr.new/@vinext/cloudflare@2593

npm i https://pkg.pr.new/create-vinext-app@2593

npm i https://pkg.pr.new/@vinext/types@2593

npm i https://pkg.pr.new/vinext@2593

commit: 766f8ce

Performance benchmarks

Compared 766f8ce against base 44ca5ab using alternating same-runner rounds. Next.js was unchanged and skipped.

0 improved · 1 regressed · 5 within ±1.5%

View detailed results and traces

_{🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head}

@codex review

/bigbonk review for issues

UnknownError: ProviderInitError

github run

@james-elicx Bonk workflow failed. Check the logs for details.

View workflow run · To retry, trigger Bonk again.

/bigbonk review for issues

UnknownError: ProviderInitError

github run

/bigbonk review for issues

UnknownError: "Overloaded"

github run

/bigbonk review for issues

UnknownError: ProviderInitError

github run

/bigbonk review for issues

UnknownError: ProviderInitError

github run

/bigbonk review for issues

fatal: could not read Username for 'https://github.com': No such device or address

github run

/bigbonk review for issues

fatal: could not read Username for 'https://github.com': No such device or address

github run

/bigbonk review for issues

Independent review: staged CDN warmup deployment

I reviewed the full diff and read the new/changed source (cdn-warm-deployment.ts, cdn-warm.ts, worker-version.ts, wrangler-deployment-target.ts, utils/toml.ts, tpr.ts, deploy.ts, init-cloudflare.ts, entry stamping) and ran tests/worker-version.test.ts + tests/cloudflare-cdn-warm.test.ts locally (27 pass).

Overall: the design is correct and I found no blocking issues. The structural insight is sound — because Workers Cache partitions its key by invoked version ID (unless cross_version_cache), a plain 2xx/3xx cannot prove the uploaded version populated the cache, so verifying via x-vinext-worker-version + a Cloudflare-Workers-Version-Overrides override (with redirect: "manual" so a redirect proves at its own cache key) is the right fix. The stage-at-0% → warm → promote → triggers-after-promotion ordering keeps the risky window in the already-safe state, strict mode fails closed by leaving the split rather than issuing an undo mutation, and getZeroPercentStagingTraffic correctly rejects partial splits / drops stale 0% leftovers / fails closed when the upload is already at 100%.

Things I verified independently:

• Traffic-split replacement: getZeroPercentStagingTraffic returns a 2-entry split which is handed to wrangler versions deploy a@100% b@0%; that command sets the full split, so any stale third version is correctly dropped.
• Env-local cache inheritance: resolveCacheConfig only falls back to the top-level cache object when the env omits it entirely (config.env?.[envName]?.cache ?? config.cache), mirroring Wrangler's whole-object inheritance — so an env that sets cache = { enabled = true } does not inherit a top-level cross_version_cache = true. Matches the tests.
• stampWorkerVersion parity: both app-router-entry and pages-router-entry stamp at the top-level fetch, and fetch-handler resolves to those, so all Worker-served responses carry the header. The status 0/101 guards for Response.error() and WebSocket upgrades, plus the immutable-headers clone fallback, are correct.
• Path-scoped carve-out: hasProductionRoute && !productionHost refuses to warm workers.dev on a different cache key, and extractWarmupHostFromCustomDomains now routes custom_domains through the same routePatternToWarmupHost host-wide guard as routes.

The prior Codex P1/P2 and the many /bigbonk rounds all appear genuinely addressed. Two small non-blocking observations (both on unchanged lines, hence a top-level comment):

1. cdn-warm.ts strict-mode throw (~line 321): the thrown strict error names only failures[0], and the warmAndPromote catch re-wraps it into the "staged at 0% and was not promoted" message, dropping the failure count entirely. The non-strict path already surfaces the warmed/total ratio in its warn; consider threading that ratio into the strict re-wrapped message too, so a CI log that truncates stdout still shows how many paths missed. Diagnostics only.

2. tpr.ts extractTomlCacheConfig (~line 634): the non-greedy /^cache\s*=\s*\{([\s\S]*?)\}/m stops at the first }, which is correct for a flat cache table but would truncate if a value inside were itself an inline table (cache = { enabled = true, nested = { a = 1 } }). Wrangler's cache table has no nested-table fields today, so valid config can't hit this — just flagging the same non-nesting assumption shared with extractTomlVersionMetadataBinding. No change needed unless the schema gains a nested field.

fatal: could not read Username for 'https://github.com': No such device or address

github run

/bigbonk review for issues

Review: staged CDN warmup deployment

I read the full diff and the changed source (cdn-warm-deployment.ts, cdn-warm.ts, version-deploy.ts, worker-version.ts, wrangler-deployment-target.ts, tpr.ts, deploy.ts, init-cloudflare.ts, entry stamping) and traced the request/deploy sequencing end-to-end.

Overall: the design is correct and I found no blocking issues. The structural fix is right — because Workers Cache partitions its key by invoked version ID (unless cross_version_cache), a plain 2xx/3xx cannot prove the uploaded version populated the cache, so verifying via x-vinext-worker-version + a Cloudflare-Workers-Version-Overrides override (with redirect: "manual" so a redirect is proven at its own cache key) is the correct approach. The stage-at-0% → warm → promote → triggers-after-promotion ordering keeps the risky window in the already-safe state; strict mode fails closed by leaving the split; getZeroPercentStagingTraffic rejects partial splits, drops stale 0% leftovers, and fails closed when the upload is already at 100%. stampWorkerVersion parity is complete (both app-router-entry and pages-router-entry stamp at the top-level fetch, and fetch-handler resolves to those). The env resolution passed from deploy.ts (env: undefined for production) is consistent with getWranglerTargetEnv, and the flattened-generated-config env fallback is handled.

The prior Codex P1/P2 items and the many /bigbonk rounds all appear genuinely addressed, each with tests. I re-confirmed the previously-flagged coverage regression (upload already at 100%) is now covered by integration tests (tests/cloudflare-cdn-warm-deploy.test.ts:680, :705).

Two small, non-blocking observations — both diagnostics/edge polish, no change required to merge:

1. Propagation budget (cdn-warm.ts:277): with the version-override defaults (retries: 3, retryDelayMs: 500) the cumulative per-path backoff is 500 + 1000 + 2000 = 3.5s (the final attempt returns without waiting). The inline comment at ~L214 notes a staged version "can take a few seconds to become globally routable," so this ceiling sits right at the edge of the documented propagation window. On a slow region a path could exhaust its retries just before the override goes live and be counted as a mismatch failure. Not a correctness bug (strict fails closed; non-strict warns and promotes), and the deploy help already tells operators to bump --warm-cdn-retries — flagging only that the default headroom is thin for the exact case this feature targets.

2. Worst-case warm-phase latency (cdn-warm.ts:268): each worker drains its share of paths serially and every path can now wait up to ~3.5s of override backoff, so with the default concurrency: 10 a site with N prerendered paths can spend up to ceil(N/10) * 3.5s in the warm phase on a slow-propagating deploy (~35s for 100 paths). Acceptable and self-limiting, but since warmup runs on the critical deploy path, a one-line note in the deploy help that large prerendered sites may extend deploy time under slow propagation would set expectations. Purely informational.

fatal: could not read Username for 'https://github.com': No such device or address

github run

Four hardening commits: 43b43ca makes "warmed" mean stored in cache, not just served; e623639 re-verifies deployment ownership before promotion; c13d76d stops init from renaming a user-owned binding; c7572ab moves Wrangler config parsing out of tpr.ts.

Warmed means stored, not just served (43b43ca)

"The uploaded version produced a 200" and "the edge stored that response in the version's cache partition" are independent facts; the transaction checked only the first. A per-entrypoint cache override or a response-level bypass (Set-Cookie, Cache-Control: no-store/private) returns a healthy 200 that Workers Cache never writes, so the deploy summary could print "pre-warmed and confirmed" over a cold cache.

Warmup requests in the deployment transaction now require cf-cache-status proof:

• HIT, STALE, UPDATING, or REVALIDATED on a version-verified response counts immediately.
• MISS or EXPIRED starts a fill, and a second identical pinned request must come back cache-served with the uploaded version's stamped header. stampWorkerVersion stores that header with the entry, so the confirm response carries the producer proof and the storage proof together.
• BYPASS, DYNAMIC, or a missing header fails the path without consuming retries: those statuses are deterministic for the response shape, and retrying returns the same answer.

The edge's own cache status is the authority, which spares vinext from modelling Wrangler cache configuration or bypass rules locally. Standalone warmCdnCache callers keep producer-only semantics unless they pass the new confirmCache option; the deployment transaction always sets it. Tests cover each status branch plus an end-to-end deploy where a producer-valid BYPASS run reports warmed: false.

Promotion re-verifies ownership of the deployment (e623639)

Promotion trusted the status read taken before staging. If another deploy promoted its own version during the warmup window, this deploy's version overrides stopped resolving (overrides apply only to versions in the current deployment), non-strict mode filed the resulting mismatches under ordinary warmup degradation, and the unconditional promotion silently overwrote the other actor's deployment.

warmAndPromote now re-reads wrangler deployments status immediately before promoting and requires the active deployment to be exactly the staged split: previousVersionId@100%, uploadedVersionId@0%, order-insensitive, no extra versions. Any other state, or a failed re-read, aborts without promoting and reports the observed traffic split. The check runs in strict and non-strict mode; non-strict relaxes how many paths must be warm, never whose deployment may be overwritten. Stale 0% versions need no tolerance here by construction: staging replaces the whole split and omits them, so a deployment this transaction still owns shows exactly the two expected versions.

Wrangler exposes no compare-and-swap, so a race remains between the final read and the promote command; the re-check shrinks the exposed window from the whole warmup duration to that gap. Tests cover the concurrent-deploy abort (another version at 100% mid-warmup rejects with zero promote or trigger commands, in non-strict mode) and the failed-re-read abort, and still assert that no reconciling status read happens after a failed promotion.

Init refuses to rename a user-owned binding (c13d76d)

With warmup enabled, init replaced any existing version_metadata binding with VINEXT_VERSION_METADATA, top-level and per-environment. The binding name is the property user code reads off env, and Workers permits one version_metadata binding per scope, so a project whose custom Worker entrypoint reads e.g. env.CF_VERSION_METADATA would keep deploying while that entrypoint silently broke.

Init now fails on a conflicting binding before mutating any project file, with instructions to rename the binding or re-run init without warmup. Where no binding exists, init still adds one. Injecting the user's own binding name into the runtime entry at build time would avoid the conflict entirely; that is deferred because it needs build-time plumbing for a situation the fail-fast already surfaces, and it can be added later without changing this behaviour.

Wrangler config parsing moved out of tpr.ts (c7572ab)

parseWranglerConfig and the WranglerConfig projection served both TPR and CDN warmup while living in tpr.ts, so wrangler-deployment-target.ts imported general deployment-config concerns (cache settings, warmup hosts, environments, version-metadata bindings) from an experimental feature module — a dependency direction that invites future deploy features to attach themselves to TPR. The parser, its helpers, and the projected types moved mechanically into wrangler-config.ts with no behaviour change: tpr.ts consumes the account/zone/KV fields, wrangler-deployment-target.ts the cache/route/environment/Worker-name/metadata fields, and utils/toml.ts stays a format-level helper.

Addressed the remaining design hole from the follow-up review in 490f7e6: supported origins can no longer hide unsupported production routes. The resolved target now carries the completeness signal the review proposed, and the transaction fails closed on it.

What changed

wrangler-config.ts — a new patternIsUnwarmable predicate captures exactly the gap: an enabled, non-workers.dev attachment whose pattern yields no concrete host-wide origin (path-scoped like blog.example.com/blog/*, or wildcard-hosted like *.example.com/*). extractHasUnwarmableRoute checks route, routes, and custom_domains in JSONC; TOML counterparts cover the scalar route, inline route tables, inline routes arrays, [[routes]] blocks, and the env-scoped variants of each. Disabled entries and workers.dev patterns don't set the flag, and the flag is scoped per environment — a path-scoped top-level route doesn't veto a deploy of an env whose own routes are all host-wide.

wrangler-deployment-target.ts — WranglerDeploymentTarget gains hasUnwarmableProductionRoute: boolean, per the review's suggested shape. When it's true, productionHosts is by definition an incomplete picture of the production cache surface.

cdn-warm-deployment.ts — in warmAndPromote, when the flag is set:

• strict mode throws before any warming (the outcome is already known), inside the transaction's catch, so the operator gets the usual previous@100% / uploaded@0% staged-state report and no promotion happens.
• non-strict still warms every reachable origin (partial warmth is still worth having) and promotes, but warmed is capped to false even when every reachable origin × path pair confirmed, with a warning naming the reason. The per-path "confirmed X/Y" warning stays tied to actual path failures so it can't read as contradictory when all reachable paths succeeded.

The previously existing conservative path is unchanged: when no origin is representable, the transaction still refuses via the empty-productionHosts branch.

Deliberately not done

No route-aware warming (intersecting warm paths against each route's pattern), matching the review's assessment that a route engine is disproportionate here. Failing closed on the completeness bit gives the same guarantee integrity at a fraction of the surface.

Verification

• Resolution tests: mixed path-scoped + host-wide (JSONC object routes, TOML inline array, repeated TOML [[routes]] blocks), wildcard + host-wide, disabled/workers.dev non-flagging, and env scoping of the veto.
• Transaction tests: the review's exact scenario (app.example.com/* + blog.example.com/blog/*) now yields warmed: false non-strict while still warming app.example.com and promoting; strict rejects with no fetch and no promotion call.
• All six affected suites green (510 tests), plus the pre-commit full check, staged tests, and knip.

Done in 878f30c — the cycle is gone, and the intended dependency direction is now real at both runtime and type level.

What changed

Two new bottom-layer modules:

• wrangler-cli.ts — owns resolveWranglerBin, buildNodeCliInvocation, validateWranglerEnvName, and the new WranglerTargetOptions type (preview/env/name/config), which previously existed only as repeated Pick<DeployOptions, ...> projections in four modules.
• utils/format-unknown-error.ts — owns formatUnknownError. This also absorbed a byte-identical private duplicate that prerender-kv-populate.ts had been carrying.

Consumers repointed downward:

• cdn-warm-deployment.ts no longer imports anything from deploy.ts. It now owns its CdnWarmupOptions type (WranglerTargetOptions + the warm knobs), and DeployOptions composes WranglerTargetOptions & CdnWarmupOptions instead of being their source — so the option shapes still have exactly one defining home each, just at the correct layer.
• One thing beyond the letter of the review: version-deploy.ts was also runtime-importing resolveWranglerBin / buildNodeCliInvocation / validateWranglerEnvName from deploy.ts (a pre-existing cycle, since deploy.ts → cdn-warm-deployment.ts → version-deploy.ts). Fixing only the transaction's imports would have moved the cycle down one level rather than removing it, so those imports now point at wrangler-cli.ts too.

The resulting graph is acyclic:

deploy.ts → cdn-warm-deployment.ts → version-deploy.ts / wrangler-deployment-target.ts → wrangler-cli.ts

Verification

Pure refactor — no behavior change intended and none observed: all six affected suites pass unchanged (510 tests; the moved helpers' existing tests now import from wrangler-cli.ts), grep confirms no ./deploy.js imports remain outside cli.ts, and the pre-commit full check + knip both pass (knip would have flagged any orphaned exports left behind in deploy.ts).